IBIS Macromodel Task Group

Meeting date: 01 March 2022

Members (asterisk for those attending):
Achronix Semiconductor:       Hansel Dsilva
Amazon:                       John Yan
ANSYS:                      * Curtis Clark
                            * Wei-hsing Huang
Cadence Design Systems:     * Ambrish Varma
                              Jared James
Google:                       Zhiping Yang
Intel:                      * Michael Mirmak
                              Kinger Cai
                              Alaeddin Aydiner
Keysight Technologies:      * Fangyi Rao
                              Majid Ahadi Dolatsara
                            * Ming Yan
                              Radek Biernacki
                              Rui Yang
Luminous Computing            David Banas
Marvell                       Steve Parker
Mathworks (SiSoft):         * Walter Katz
                              Mike LaBonte
Micron Technology:            Randy Wolff
                            * Justin Butterfield
Missouri S&T                  Chulsoon Hwang
Siemens EDA (Mentor):       * Arpad Muranyi
Teraspeed Labs:             * Bob Ross
Zuken USA:                  * Lance Wang

The meeting was led by Arpad Muranyi.  Curtis Clark took the minutes.

--------------------------------------------------------------------------------
Opens:

- None.

-------------
Review of ARs:

- Arpad to send out BIRD213.1 draft 14 incorporating the meeting's changes.
  - Done

--------------------------
Call for patent disclosure:

- None.

-------------------------
Review of Meeting Minutes:

Arpad asked for any comments or corrections to the minutes of the February 22nd
meeting.  Michael moved to approve the minutes.  Curtis seconded the motion.
There were no objections.

-------------
New Discussion:

BIRD213.1 draft 14, PAMn:
Arpad shared draft 14.  Michael reported that he had been receiving inquiries
from many people who were eager to see this functionality added to the
specification.  Michael asked for confirmation that the BIRD left the mapping of
symbols to PAMn levels up to the tools.  Arpad agreed.  Fangyi said the original
draft contained mapping information, but that Ambrish had rightly pointed out
that mapping should be the job of the EDA tool.  For example, IBIS doesn't get
involved with 8b10b encoding.  Michael said IBIS is sticking at the PHY layer
and not getting involved with encoding.  Fangyi and Ambrish agreed.  Arpad
noted that IBIS hadn't been entirely consistent on this point, and legacy PAM4
parameters included PAM4_Mapping, which mentions Gray code.

Fangyi noted an inconsistency, in the Usage Rules for PAM_Thresholds, in the
language used to describe the location of the "eyes".  The second paragraph of
the section described the progression of eyes:
   "The eye with the lowest threshold voltage is eye "1", the eye with the
    next threshold voltage up is eye "2", ..."
In the bulleted list that follows, however, the definitions of the voltage
ranges corresponding to symbol values referred to rows in the PAM_Thresholds
Table.  That is, eye 1 corresponds to the value in row 1 of the
PAM_Thresholds parameter, eye 2 corresponds to row 2, etc.

Fangyi said it was inconsistent to talk about the lowest threshold voltage in
one instance and the first row (first value) in the table in another instance.
Fangyi said the second paragraph implied tools should sort the thresholds.
Walter said that as you proceed up in rows the thresholds should be increasing.
Fangyi asked if we should enforce that monotonicity in values returned by the
model.  Arpad asked if there would be any expectation that they could be out of
order.  Fangyi said that as a practical matter, if they're out of order, then
the design has probably failed.  He said model makers were probably the best
people to decide if this language was an issue.  If we were to keep the language
as written, then we could not model any swizzling of the thresholds. Justin said
he didn't have a strong opinion at this point and wasn't sure if it would ever
become an important distinction.

Arpad asked if the language was sufficient for us to vote to move it to the Open
Forum.  Curtis said he thought we should clean up the inconsistency Fangyi had
pointed out.  Fangyi took an AR to propose new language based solely on row
entry not threshold voltage value.

Walter recalled that Ambrish had suggested that instead of Tables we use String
Type parameters whose values are space delimited lists of numbers for
PAM_Offsets and PAM_Thresholds.  Walter had added an example of such an approach
in the BIRD as a place holder.  Ambrish agreed that this was his suggestion.

Ambrish moved to use String Type parameters instead of Tables for PAM_Offsets
and PAM_Thresholds.  Arpad said he was somewhat sympathetic to this suggestion
and that tables could be more complex to understand and parse in the .ami file.
Curtis said he was interested in the group discussing it further.  Curtis
seconded Ambrish's motion.  Bob said he preferred the Table, and he saw no
reason to introduce any extra complexity in the text to define the contents of
the String.  With the current approach, it's just a Table of Floats and
everything is understood.  Walter said he thought the Table was the AMI way to
do it, but he had no major objection to the String suggestion.  He said he would
abstain from any vote and leave it to the rest of the group.

Arpad asked model makers which one they thought would be easier and whether we
should consider allowing both.  Curtis said he would probably not vote for
allowing both methods.  We should pick one and stick with it.  The group
discussed issues with how a single String value would be parsed and how
hard it would be to define the numerical format of the String value.  Some
attendees suggested that it would take too much effort to capture the definition
of the single String value in the specification.  Michael said that on one hand
he agreed that Tables aren't seen that often in the wild.  However, he said
feedback he was receiving indicated that people wanted this functionality as
soon as possible.  He wasn't sure it was worth delaying its progress to discuss
use of String Type parameters.  Ambrish withdrew his motion with the
understanding that he might make it again at a later date.

AMI Parameter tree root name clarifications BIRD draft:
Michael reported that he had received no new feedback since publishing draft 3,
aside from Arpad's comments, which had been set to the ATM list in reply.

- Michael: Motion to adjourn.
- Curtis: Second.
- Arpad: Thank you all for joining.

AR: Fangyi to propose language changes for PAM_Thresholds Usage Rules in
    BIRD213.1.
    
-------------
Next meeting: 08 March 2022 12:00pm PT
-------------

IBIS Interconnect SPICE Wish List:

1) Simulator directives
